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Dear Sir: 

Applicants respectfully submit that the Examiner's rejections include clear errors because 
the references fail to teach what is alleged and the references fail to teach the claimed subject 
matter. 

Claims 11-16 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over U.S. Patent No. 6,295,461 (Brown) in view of "Designing a PC Game Engine" by L. 
Bishop, D. Eberly, T. Whitted, M. Finch and M. Shantz (Bishop). 

Applicants respectfully submit clear error exists because the Brown reference renders an 

object before determining its visibility, whereas claim 11 recites making a determination 

regarding visibility based on a draw packet prior to rendering the draw packet. Claim 1 1 recites 

in part an apparatus that 

compares each of the plurality of draw packets to a bounding volume object , 
wherein the bounding volume object is a low resolution geometric representation 
of a specific object identified as geometry through which viewing definitions are 
defined; 

for each of the plurality of draw packets, if the draw packet is deemed potentially 
visible, sets a visibility query identifier for the draw packet , and using at least one 
of a plurality of identifiers that defines which of a plurality of hardware queries is 
to be updated; and 

renders one or more draw packets having the set visibility query identifier (Claim 
11; emphasis added). 

Brown does not teach at least the recited limitation of comparing draw packets to a 
bounding volume object . The Final Office Action dated March 4, 2011 (hereinafter the Office 
Action) alleges that 
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The limitation "compares each of the plurality of draw packets to a bounding 
volume object, wherein the bounding volume is a low resolution geometric 
representation of a specific object" is taught by Brown ( col 7, lines 13-25 ) (Office 
Action, pg. 8; emphasis added). 

The cited portion of Brown reads: 

In similar fashion, when an application program 102 is configured to display a 
graphics scene that requires the rendering of relatively complex (i.e., 
computationally extensive) graphics shapes or objects, the application program 
102 may be segmented by a developer to first send a relatively simplified version 
of the object or shape to be rendered to the graphics pipeline, and thereafter test 
the visibility of flag 110. If the visibility flag indicates that no part of the shape 
was rendered , then the application program 102 may skip over subsequent 
graphics calls that would further render the shape or object . In this way, otherwise 
unnecessary computations may be saved by selective and careful programming at 
the application program 102 level (Brown, col. 7 Ins. 13-25; emphasis added). 

It is respectfully submitted that the cited portion of Brown does not teach a comparison 

between draw packets and a bounding volume object as alleged. Rather, in the cited portion, 

Brown teaches that a "visibility flag" is set for a shape only after a first rendering pass on the 

shape has been completed. As taught by Brown, the visibility flag indicates that a shape has 

been successfully rendered . Rather than comparing draw packets to a bounding volume, Brown 

teaches subsequent rendering passes are prevented on objects that have been determined to be 

non-visible based on a previous rendering pass. In other words, Brown teaches a method 

whereby multiple passes are used to render objects; a first rendering pass is performed on every 

object of a graphic display while subsequent rendering passes are only performed on visible 

objects (see e.g. Brown, Figs. 5 & 6 and col. 8 In. 31 - col. 9 In. 42). Thus, the method taught by 

Brown is incapable of determining if a particular object will be non-visible without first 

completing a rendering pass. Further, as argued on pages 6-7 of the previous Response (dated 

February 15, 2011), Brown explicitly teaches that the visibility flag is only set when graphics 

data representing the object has been rendered and is transmitted to the frame buffer. For 

example, Brown states that 

when the application program 102 performs a graphics call that specifies a 
primitive to be filled on a "first pass", it may thereafter check the visibility flag 
110 to see if , in fact, any portion of that primitive was sent to the frame buffer 108 
for display (Brown, col. 7 Ins. 1-5; emphasis added; see also Brown, col. 6 Ins. 
35-38 and 51-55). 
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As best understood, the Office Action alleges that "Brown explicitly indicates that there 
is an alternate way to control the visibility flag" aside from mechanism 112 and that this 
"alternate way" reads on Applicants' recited approach (Office Action, pg. 11). However, 
Applicants respectfully submit that the "alternate way" of setting the visibility flag is for 
rendering pipeline 106 to control mechanism 112 to set the visibility flag when graphics data is 
sent to the frame buffer for display (see e.g. Brown, col. 6 Ins. 55-57). In other words, the 
visibility flag is set for an object when graphics data representing that object is sent to the frame 
buffer; this process can be controlled by either mechanism 112 or rendering pipeline 106. 
Accordingly, both alternatives require that an object must be rendered to the frame buffer before 
a determination can be made regarding its visibility. 

In sharp contrast to Brown, Applicants recite an apparatus capable of evaluating the 
visibility of draw packets before they are rendered. Accordingly, a first rendering pass is not 
required on objects that will not be visible. For example, as discussed in Applicants' 1 0011, a 
bounding object through which viewing definitions may be defined (such as a window or 
doorway) can be used to determine whether draw packets are potentially visible. Thus, objects 
determined to be non- visible are not rendered (see e.g. Applicants' ff 0001 and 0016-0017). As 
is clear to one of ordinary skill in the art, Applicants' recited method offers several advantages 
over that taught by Brown, including for example reducing the amount of processing overhead 
required to display a graphics image by not conducting a first rendering pass on non-visible 
objects. 

It is respectfully submitted that further clear error exists because Brown does not teach or 

suggest "draw packets" as recited by Applicants. For example, the Office Action alleges that 

"Brown's 'segments' correspond to Applicant's 'packets', which can represent any object 

segmentation scheme desired by a developer" (Office Action, pg. 12; emphasis added). More 

specifically, the Office Action alleged that 

The limitation "receives a plurality of draw packets" is taught by Brown (as 
indicated in col 3, lines 36-56 , as quoted in the claim 21 rejection, graphics data is 
broken up into segments, i.e. the first segment, and others ) (Office Action, pg. 8; 
emphasis added). 

The cited portion of Brown reads: 

The method operates in a computer graphics system having an application 
program that interfaces through an application program interface (API) to a 
graphics pipeline, including a rendering pipeline and a frame buffer. The method 
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includes the step of providing a visibility 40 flag that is in communication with 
the application program to relay rendering information to the application program. 
The method clears (or resets) the visibility flag upon sending new data to the 
rendering pipeline, and sets the visibility flag if data sent to the rendering pipeline 
from the application 45 program is further communicated to the frame buffer for 
display. Thereafter, the method evaluates the visibility flag from within the 
application program after a first pass of a first segment of graphics data has been 
rendered by the rendering pipeline. If the visibility flag was not set during 50 the 
first pass, then the application program inhibits the rendering of subsequent passes 
of the first segment of graphics data . If, however, the visibility flag was set during 
the first pass, then the application program will send subsequent passes of the 
graphics data to the rendering pipeline 55 for processing and display (Brown, col. 
3 Ins. 36-56; emphasis added). 

As shown in the cited portion above, Brown does not teach or suggest draw packets . 

Instead, Brown merely describes how graphics data can be divided into multiple segments that 

can be separately sent to a rendering pipeline. For example, Brown describes these segments of 

graphics data by stating that 

when an application program 102 is configured to display a graphics scene that 
requires the rendering of relatively complex (i.e., computationally extensive) 
graphics shapes or objects, the application program 102 may be segmented by a 
developer to first send a relatively simplified version of the object or shape to be 
rendered to the graphics pipeline ... (Brown, col. 7 Ins. 13-19). 

Accordingly, it is respectfully submitted that as best understood, Brown teaches that the 
"segments of graphics data" comprise simplified versions of objects or shapes. In other words, 
Brown necessarily makes determinations regarding visibility on a rendered object or shape level. 
In sharp contrast thereto, Applicants explicitly recite using draw packets prior to rendering as a 
basis for determining whether a draw packet is potentially visible and should be rendered. 

Claims 21, 2, 3, 5 and 6 stand rejected under 35 U.S.C. § 102(b) as allegedly being 
anticipated by Brown. Applicants respectfully reassert the relevant remarks made above and as 
such, there is clear error with regard to these claims as well. 

Claim 20 stands rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable over 
Brown as applied to claim 3 above and further in view of "ARB_occlusion_query" by R. 
Cunniff, M. Craighead, D. Ginsburg, K. Lefebvre, B. Licea-Kane, and N. Triantos (Cunniff). 
Applicants respectfully reassert the relevant remarks made above and as such there is clear error 
with regard to these claims as well. 



CHICAGO/#2226250.1 



4 



Withdrawal of the rejections of the claims is respectfully requested due to at least one or 
more clear errors by the Examiner, and a Notice of Allowance is respectfully requested. 



Respectfully submitted, 

Date: August 4, 2011 By: /Christopher J. Reckamp/ 

Christopher J. Reckamp 
Registration No. 34,414 

Vedder Price P.C. 

222 North LaSalle Street, Suite 2600 
Chicago, Illinois 60601 
phone: (312) 609-7599 
fax: (312) 609-5005 
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